Database Host Size Based on Annual TEU

The following graphs show the transaction volumes generated by N4 in typical installations with varying TEU. Use this as a guideline for understanding the number of transactions per minute (TPM) that the database needs to support, as well as the storage requirements based on the volume, and the number of years of historical data that needs to be available. For a list of supported operating systems and hardware requirements, see Operating System and Hardware Requirements (on page 1). For information about how VMs are supported for N4 databases, see Virtual Platforms (on page 1).

The scaling is broad enough to cover the requirements for everything from a basic installation, without licensable options, to one in which you have licensed some or all Planning and Control options, including the ECN4/ECN4Web host and N4 Mobile.

These numbers will not apply if:

    The database host is running multiple databases

    Additional reporting and processing operations are running against the application database (custom Groovy, iReports, etc.)

Figure 4: N4 Database Server Scaling Based on Annual TEU for Non-Automated Terminals

For N4 Automation sites: The following graph assumes N4 Automation sites have greater than 500,000 annual TEU. If you have less than 500,000 TEU, consult with Navis for recommendations.

Figure 5: N4 Database Server Scaling Based on Annual TEU for Automated Terminals

The disk space numbers are based on a conservative estimate.

Notes Specific to Oracle

Typical Archive Log File Sizes are:

• Site Example 1: Volume 1.7 Million TEU has archive log sizes of 13-14 GB archive file size per day

• Site Example 2: Volume 400 Thousand TEU has 1.5 - 2 GB archive file size per day

Notes Specific to Oracle RAC

Each node in the Oracle RAC environment should satisfy requirements from the chart above. The minimum number of nodes is two.

Configuring the N4 application in an Oracle RAC environment has two major benefits:

• high availability

• scalability

N4 supports Fast Connection Failover, which provides high availability of the application.

The number of nodes in Oracle RAC provides application scalability in case of a high number of simultaneous user sessions.

Notes Specific to SQL Server

If you are using SQL Server with the Always On Availability Group feature for your disaster recovery, you have the option to use the synchronous-commit mode or the asynchronous-commit mode for replication.

• The synchronous-commit mode ensures there is no data loss for committed transactions. The primary replica sends transactions to the secondary replica and waits for the transactions to be committed. This adds latency to each transaction as each transaction requires an acknowledgment from the replica database before it is complete. If you choose this option, consider your database size and the potential impact on N4 performance.

• The asynchronous-commit mode minimizes latency as each transaction is completed on only the primary database. The primary replica does not wait for the acknowledgment for a transaction commit. However, if there is a lag in updating the secondary replica, then there is potential for some data loss in the event of a failover.

You can use either option with N4. Due to the critical nature of on-going operations in N4 and for best system performance, Navis recommends that you use the asynchronous-commit mode.